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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 

The IM CN subsystem interworks with the external IP networks through the Mb reference point. 

This document details the interworking between the IM CN subsystem and external IP networks for IM service support. 
It addresses the issues of control plane interworking and, user plane interworking for specific interworking use cases. 
Clause 10 describes the IMS-Ix interface requirements in the form of Use Cases which require H.248 protocol 
procedures. Subclause 10.4 then details the additional Information Elements required to perform the specific 
procedures. 

The IP version Interworking, between IP version 4 RFC 791 [9] and IP version 6 RFC 2460 [10] detailed in terms of the 
processes and protocol mappings required in order to support both mobile originated and terminated calls. 

2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document 
(including a GSM document), a non-specific reference implicitly refers to the latest version of that document in 
the same Release as the present document. 

[I] 3GPP TS 24.229: "Internet Protocol (IP) multimedia call control protocol based on Session 
Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3". 

[2] IETF RFC 3261: "SIP: Session Initiation Protocol". 

[3] 3GPP TS 23.221: "Architectural requirements". 

[4] 3GPP TS 29.061: "Interworking between the Public Land Mobile Network (PLMN) supporting 

packet based services and Packet Data Networks (PDN)". 

[5] 3GPP TS 23.002: "Network architecture". 

[6] 3GPP TS 26.235: "Packet switched conversational multimedia applications; Default codecs". 

[7] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[8] 3GPP TS 23.228: "IP Multimedia Subsystem (IMS); Stage 2". 

[9] IETF RFC 79 1 : "Internet Protocol" . 

[10] IETF RFC 2460: "Internet Protocol, Version 6 (IPv6) Specification". 

[II] IETF RFC 2766: "Network Address Translation - Protocol Translation (NAT-PT)". 

[12] IETF RFC 2663: "IP Network Address Translator (NAT) Terminology and Considerations". 

[13] 3GPP TR 29.962 version 6.1.0: "Signalling interworking between the 3GPP profile of the Session 

Initiation Protocol (SIP) and non-3GPP SIP usage". 

[14] ITU-T Recommendation H.263: "Video coding for low bit rate communication". 

[15] ITU-T Recommendation G. 723.1: "Dual rate speech coder for multimedia communications 

transmitting at 5.3 and 6.3 kbit/s". 
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[16] ITU-T Recommendation G.729: "Coding of speech at 8 kbit/s using conjugate-structure algebraic- 

code-excited linear-prediction (CS-ACELP)". 

[17] ITU-T Recommendation G.711: "Pulse code modulation (PCM) of voice frequencies". 

[18] IETF RFC 792: "Internet Control Message Protocol". 

[19] IETF RFC 2463 : "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 

6". 

[20] IETF RFC 2765: "Stateless IP/ICMP Translation Algorithm (SITT)". 

[21] 3GPP TS 24.608: "Terminating Identification Presentation (TIP) and Terminating Identification 

Restriction (TIR) using IP Multimedia (IM)Core Network (CN) subsystem; Protocol specification'. 

[22] IETF RFC 3323: "A Privacy Mechanism for the Session Initiation Protocol (SIP)". 

[23] IETF RFC 3325: "Private Extensions to the Session Initiation Protocol (SIP) for Network Asserted 

Identity within Trusted Networks". 

[24] 3GPP TS 24.628: "Protocols for Advanced Networking (TISPAN); Common Basic 

Communication procedures; Protocol specification". 

[25] 3GPP TS 29.238: "Interconnection Border Control Functions - Transition Gateway; H.248 Profile; 

Stage 3". 

[26] ITU-T Recommendation H.248. 1 (05): "Gateway Control Protocol: Version 3". 

[27] Void 

[28] 3GPP TS 23.205: "Bearer-independent circuit-switched core network; Stage 2". 

[29] 3GPP TS 29.235: "Interworking between SIP-I based circuit-switched core network and other 

networks". 

[30] IETF RFC 3550: "RTP: A Transport Protocol for Real-Time AppUcations". 

[31] IETF RFC 2474: "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 

Headers". 

[32] 3GPP TS 33.328: "IMS Media Plane Security". 

[33] IETF RFC 4568 (2006): "Session Description Protocol (SDP) Security Descriptions for Media 

Streams". 

[34] IETF RFC 37 1 1 (2004): "The Secure Real-time Transport Protocol (SRTP)" . 

[35] IETF RFC 5 124 (2008): "Extended Secure RTP Profile for Real-time Transport Control Protocol 

(RTCP)-Based Feedback (RTP/SAVPF)". 

[36] 3GPP TS 26. 114: "IP Multimedia Subsystem (IMS); Multimedia Telephony; Media handhng and 

interaction" . 

[37] IETF RFC 3 1 68 : "The Addition of Explicit Congestion Notification (ECN) to IP" . 

[38] IETF draft-ietf-avtcore-ecn-for-rtp-00: "Explicit Congestion Notification (ECN) for RTP over 

UDP". 

Editor's Note: The above document cannot be formally referenced until it is published as an RFC. 

[39] 3GPP TS 29.079: "Optimal Media Routeing within the IP Multimedia Subsystem; Stage 3" 
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Definitions, symbols and abbreviations 



3.1 



Definitions 



For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [7] and the following 
apply: 

IM CN subsystem: (IP Multimedia CN subsystem) comprises of all CN elements for the provision of IP multimedia 
applications over IP multimedia sessions 

IP multimedia session: set of multimedia senders and receivers and the data streams flowing from senders to receivers 
IP multimedia sessions are supported by the IP multimedia CN Subsystem and are enabled by IP connectivity bearers 
(e.g. GPRS as a bearer). A user may invoke concurrent IP multimedia sessions. 

MSC Server enhanced for ICS: An MSC Server that supports the network based ICS functionality. 

3.2 Symbols 

Void. 



3.3 



Abbreviations 



For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 [7] and the following apply: An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
3GPPTR 21.905 [7]. 

BGCF Breakout Gateway Control Function 

ECN Explicit Congestion Notification 

ECN-CE ECN Congestion Experienced 

IBCF Interconnect Border Control Function 

ICS IMS CentraUzed Services 

I-CSCF Interrogating CSCF 

IMS-ALG IMS - Application Level Gateway 

ITU-T International Telecommunication Union - Telecommunication Standardization Sector 

MRFP Multimedia Resource Function Processor 

NAT/NAPT Network Address Translation / Network Address and Port Translation 

NA (P) T-PT Network Address (and Port) Translation - Protocol Translation 

OMR Optimal Media Routeing 

P-CSCF Proxy CSCF 

RTCP Real Time Control Protocol 

SCTP Stream Control Transmission Protocol 

SIP UA SIP User Agent 

SIP Session Initiation Protocol 

THIG Topology Hiding Internetwork Gateway 

TrGW Translation Gate Way 

WAN Wide Area Network 



General 



4.1 General interworking overview 

The IM CN Subsystem interworks with SIP IETF RFC 3261 [2] based IP Multimedia networks. These IP Multimedia 
networks include: 

- SIP User Agents (UAs); 
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- SIP Servers. 

As such, the IM CN Subsystem has to be able to interwork to all of these above functional entities in the IP multimedia 
network, as there is a possibility that they all may be involved in an IM session. The general interworking model is 
shown in figure 1. The SIP based Multimedia networks may use IP version 4 IETF RFC 791 [9] or IP version 6 IETF 
RFC 2460 [10]. 



MSC Server 
enhanced 
for ICS 




Signalling 
Bearer 



IM CN subsystem network 



IP multimedia network 



Figure 1 : Interworking Model for IM CN Subsystem to IP Multimedia Network 

The UE uses the CSCF in order to communicate with the external IP multimedia network entities. 

If no IP version interworking or no NAT/NAPT between different realms is required, the CSCF can communicate with 
SIP UAs in an external IP multimedia network directly. 

If no IP version interworking or no NAT/NAPT between different realms is required, the CSCF can also communicate 
with SIP proxies in an external IP multimedia network directly, which in turn can then communicate with SIP UAs. 

To provide the IP version interworking or NAT/NAPT between different realms the functions of an IMS-ALG and a 
TrGW may be inserted between the CSCF and external IP Multimedia Network by configuration. The IMS-ALG and 
the TrGW may be implemented as a part of other physical entities in the IMS. 

NOTE: Other methods to provide IP version interworking are for further study. 



4.2 Interworking scenarios 



3GPP specifications design the IM CN subsystem elements and interfaces to exclusively support IPv6. 
3GPP TS 23.221 [3] details the interoperability scenarios that an UE may experience when interworking with an 
external PDN. All of these IP transport layer interworking scenarios can apply to the application layer interworking 
scenarios detailed in clause 4.2.1. 

4.2.1 UE with 3GPP SIP profile capability connecting to an external SIP 
device 

The procedures used by an UE with 3GPP SIP profile to connect to an external SIP device, which may lack 3GPP SIP 
profile capabilities, have been analysed in Release 6 within 3GPP TR 29.962 [13] and are specified in 3GPP TS 24.229 
[1]. 
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Network characteristics 



5.1 Key characteristics of IP IVIultimedia Networks 

The Internet is a conglomeration of networks utilising a common set of protocols. IP protocols are defined in the 
relevant IETF RFCs. The networks topologies may be based on LANs (e.g. Ethernet), Point-to-Point leased lines, 
PSTN, ISDN, X.25 or WANs using switched technology (e.g. SMDS, ATM). 

IP multimedia networks provide the ability for users to invoke IP multimedia applications in order to send and receive 
(where applicable) voice and data communications. One protocol used to manage IP multimedia sessions is the Session 
Initiation Protocol (SIP) (RFC 3261 [2]). 

5.2 Key characteristics of UIVITS IIVI CN Subsystem 

The UMTS IM CN subsystem uses the SIP protocol to manage IP multimedia sessions, and uses IP as the transport 
mechanism for both SIP session signalling and media transport. 

The UMTS IM CN subsystem shall support interworking with existing fixed and mobile voice and IP data networks, 
including PSTN, ISDN, Mobile and Internet. 



6 Interworking Reference IVIodel for control plane 

interworking and user plane interworking 

Figure 2 details the reference architecture required to support interworking between the IM CN subsystem and IP 
networks for IM services. Figure 3 details the reference architecture required to support interworking between the IMS 
and IP SIP networks supporting IP version 4. 



CSCF 



I 



Mm 



Mb 




NOTE: Multimedia IP networks may be connected via the Mb interface to various network entities, such as an UE 
(via an GTP Tunnel reaching to the GGSN), an MRFP, or an application server. 

Figure 2: IM CN Subsystem to IP network interworking reference Architecture without IP version 

interworking 
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Figure 3: Border Control Functions 

Mm reference point: The call control protocol applied to the Mm interface between CSCF and external IP networks is 
SIP, RFC 3261 [2], as detailed in 3GPP TS 24.229 [1]. SIP extension packages mandated by 3GPP are possibly not 
supported. 

Mb reference point: This interface is defined in 3GPP TS 23.002 [5] and is IP based. Further information is provided 
in 3GPP TS 29.061 [4] and 3GPP TS 26.235 [6]. 

Mx reference point: The protocol applied at the Mx reference point is specified in 3GPP TS 24.229 [1]. 

Ix reference point: The protocol applied at the Ix reference point is specified in 3GPP TS 29.238 [25]. 



6.1 Interworking Functional Entities 



6.1.1 



IBCF 



This entity provides control plane functionality to connect entities following the 3GPP profile of SIP, 3GPP TS 24.229 
[1], and external SIP entities following IETF RFC 3261 [2]. 

6.1.2 IMS-ALG 

IMS-ALG functionality resides in IBCF. An IMS-ALG provides the application level translation function for SIP and 
SDP in order to communicate between IPv6 and IPv4 SIP applications or, based on operator policies between different 
realms using the same IP version. The IBCF acts as a B2BUA when it performs IMS-ALG functionality. 

6.1.3 TrGW 

The TrGW is a NAT-PT/NAPT-PT, which uses a pool of globally unique IPv4 addresses for assignment to IPv6 nodes 
on a dynamic basis as sessions are initiated across the IP version boundaries. NAT-PT binds addresses in IPv6 network 
with addresses in IPv4 network and vice versa to provide transparent routing between the two IP domain without 
requiring any changes to end points. NAPT-PT provides additional translation of transport identifier (TCP, SCTP and 
UDP port numbers). More detailed information on the NAT-PT/NAPT-PT is given in RFC 2766 [11] and RFC 2663 
[12]. 
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The TrGW may provide the NAT/NAPT functionality between two disparate address realms. 

7 Control plane interworking 

7.1 SIP with 3GPP Profile to Standard SIP Interworking 

3GPP TS 24.229 [1] defines the procedures, which allow a 3GPP-IMS UE to connect to a standard SIP terminal. 

7.2 Additional interworking of protocol associated with 
supplementary services 

7.2.1 General 

This is no impact beyond that specified in subclause 7.1 provided the necessary SIP extensions are supported on both 
sides of the interworking point unless otherwise specified by subsequent subclause. Based on operator policy and/or 
service level agreements the interworking of services may be restricted. 

Editor" s Note: Impacts when the service is restricted or not supported on one of the interfaces is FES. 

7.2.2 Terminating Identification Presentation (TIP) and Terminating 
Presentation Restriction (TIR) 

See 3GPP TS 24.608 [21] for a description of the service. 

If the other IP network is a trusted network and the REC 3323 [22] and REC 3325 [23] are supported the following 
header fields shall be forwarded without changes: 

• P-Asserted-Identity header field; and 

• Privacy header field. 

If the IP network is not trusted the P- Asserted- Identity header field shall be removed from SIP requests and SIP 
responses. 

7.2.3 Common Basic Communication 

See 3GPP TS 24.628 [24] for description of service. 

Depending on the external IP network and message direction, the IBCE may have a local policy to remove an Error-Info 
header field, Call-Info header field and/or an Alert-Info header field. 



8 User Plane Interworking 

8.1 Overview 

The present specification addresses user plane interworking between codec types used for either speech or video. 
Codecs used for conversational services in the PS domain are as defined in 3GPP TS 26.235 [6]. Codecs of particular 
interest are described in annex A. 



8.2 VOID 
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8.3 VOID 

9 IMS-ALG and TrGW functionality for NAPT and IP 

Version Interworking 

9.1 Control plane interworking 

9.1.1 Session Set-up 

9.1.1.0 General 

The procedure described in Clause 9.1.1 applies both for an SDP offer received from the external network and received 
from the IMS. 

If different IP versions are used in the external network and the IMS, the TrGW shall provide IP version interworking of 
the user plane. Otherwise, it provides NAPT functionality. 

9.1 .1 .1 Receipt of the first SDP offer 

At the receipt of the first SDP offer from an offering network A the IMS-ALG shall: 

Request the TrGW to allocate a termination towards an answering network B and provide IP address(es) and port 
number(s) from its pool for this termination. 

When the IMS-ALG has received the requested information from the TrGW, the IMS-ALG shall include the 
address(es) and port number(s) in a new offer, and sent this offer toward the network B. The IMS-ALG shall create a 
SIP message in accordance with the rules for the IMS_ALG described in subclause 9.1.4 with the following 
clarification: 

The IP address(es) and port number(s) received from the TrGW for the termination towards network B shall 
replace the IP address(es) and port number(s) in the SDP. 

9.1 .1 .2 Receipt of the first SDP answer 

At the receipt of the first SDP answer from network B the IMS-ALG shall: 

Provide to the TrGW the address(es) and port number(s) as received in the c-line(s) and m-line(s) in the SDP 
answer as destinations for the termination towards answering network B, 

Request the TrGW to allocate a termination towards the offering network A and provide IP address(es) and port 
number(s) from its pool for this termination, and provide the IP address and port number received in the first 
SDP offer from network A as destination for this termination, unless this step has already been executed earlier, 
e.g. at the receipt of the SDP offer, and 

Requests the TrGW to bind the termination towards network A and the the termination towards network B to 
enable the routing of user plane traffic towards the IPv4 SIP network through the TrGW. 

Note: The binding request will be combined with the request to create terminations in the H.248 protocol 

When the IMS-ALG has received the requested information, the IMS-ALG shall send an SDP answer to the network A. 
The IMS-ALG shall create the SIP message in accordance with the rules for the IMS ALG described in subclause 9.1.4 
with the following clarification: 

The IP address(es) and port number(s) received from the TrGW for the termination towards network A shall 
replace the received IP address(es) and port number(s) in the SDP. 
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9.1.2 Void 

9.1 .3 Change of connection information 

After the dialog is established it is possible for both ends of the session to change the connection data for the session. 
When the IMS-ALG/TrGW receives a SDP offer/answer where port number(s) or IP address(es) is included., there are 
four different possibilities: 

1) IP address(es) or/and port number(s) have been added. In this case additional binding(s) shall be provided by the 
IMS-ALG/TrGW as detailed for the first SDP offer in the Clauses above; 

2) IP address(es) or/and port number(s) have been deleted. In this case binding(s) shall be made free by the IMS- 
ALG/TrGW; 

3) IP address(es) and port number(s) have been reassigned of the users. In this case the binding(s) shall reflect the 
reassignment; 

4) No change has been made to the IP address(es) and port number(s). In this case no change shall be made to the 
existing binding(s). 

9.1 .4 Interworking of SIP messages 

The IMS-ALG behaves as a SIP B2BUA when interworking SIP messages. The IMS-ALG shall forward all SIP 
messages transparently with respect to all methods, result codes, headers and attachments except as follows: 

- The IMS-ALG modifies SDP according to subclauses 9.1.1, 9.1.2 and 9.1.3; 

When forwarding an incoming SIP request, the IMS-ALG should perform UAC procedures towards the intended 
target according to IETF RFC 3261 [2], by modifying those headers necessary to ensure that all transactions 
within the dialog pass through the IMS-ALG; 

When forwarding an incoming SIP response, the IMS-ALG should perform UAS procedures towards the 
originator of the corresponding request according to IETF RFC 3261 [2], by modifying those headers necessary 
to ensure that all transactions within the dialog pass through the IMS-ALG; and 

The IMS-ALG may perform any appropriate error recovery procedures in the event that an incoming message 
contains errors inconsistent with the forwarding procedures above. 

At the receipt of a BYE request, CANCEL request or non-200 final response, the IMS-ALG shall release the session 
and request the TrGW to release the bindings established for the session. 

9.2 User plane transport 
9.2.1 Payload transport 

The TrGW shall use the established bindings described above to transport the messages between the network A and the 
network B in the following way. 

At the receipt of a payload message the TrGW shall: 

Replace the received destination IP address(es) and port number(s) in the payload message with the 
corresponding IP address(es) and port number(s) that have been signalled by the IBCF.- Replace the received 
source IPaddress(es) and port number(s) in the payload message with the corresponding IPaddress(es) and port 
number(s) the TrGW allocated at its own terminations. 
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9.2.2 IP header interworking 



9.2.2.1 



IPv4 to IPv6 



When the TrGW receives an IPv4 message the following codings shall be set in the IPv6 headers of the message sent to 
the IPv6 network. 

If the DF bit is set and the packet is not a fragment (i.e., the MF flag is not set and the Fragment Offset is zero) 
The IPv6 headers shall be set as described in Table 1 ; 

If the DF bit is not set or the packet is a fragment the IPv6 headers shall be set as described in Table 2. 
Table 1 : Derivation of IPv6 Header from IPv4 header (no fragmentation) 



IPv6 field 


Value 


Version 


6 


Traffic Class: 


The default behaviour is that the 
value of the IPv6 field Traffic Class 
field is the value of the IPv4 Type 
Of Service field (all 8 bits are 
copied). An implementation of a 
TrGW should also provide the ability 
to ignore the value of the IPv4 Type 
of Service and always set the IPv6 
traffic class field to zero. 


Flow label 


The Ipv6 Flow Label Field is set to 
(all zero bits) 


Payload Length 


The IPv6 Payload Length field value 
is the IPv4 Total length field value 
minus the size of the IPv4 header 
and IPv4 options field length, if 
present. 


Next Header 


The Ipv6 Next Header value is 
copied from IPv4 Protocol field 


Hop Limit: 


The IPv6 Hop Limit value is The 
value of IPv4 field Time To Live 
minus 1 


Source Address 


Shall be handled as the addresses 
of the payload message as 
described in subclause 9.2.1. 


Destination Address 


Shall be handled as the addresses 
of the payload message as 
described in subclause 9.2.1. 



Table 2: Derivation of IPv6 Header from IPv4 Header (fragmentation) 



IPv6 field 


Value 


Version 


6 


Traffic Class: 


The default behaviour is that the 
value of the IPv6 field Traffic Class 
field is the value of the IPv4 Type Of 
Service field (all 8 bits are copied). 
An implementation of a TrGW 
should also provide the ability to 
ignore the value of the IPv4 Type of 
Service and always set the IPv6 
traffic class field to zero. 


Flow label 


The Ipv6 Flow Label Field is set to 
(all zero bits) 


Payload Length 


The IPv6 Payload Length field value 
is the IPv4 Total length field value 
plus 8 for the fragment header 
minus the size of the IPv4 header 
and IPv4 options field length, if 
present. 
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IPv6 field 


Value 


Version 


6 


Next Header 


The IPv6 Next header field is set to 
Fragment header (44). 


Hop Limit: 


The IPv6 Hop Limit value is The 
value of IPv4 field Time To Live 
minus 1 


Source Address 


Shall be handled as the addresses 
of the payload message as 
described in subclause 9.2.1. 


Destination Address 


Shall be handled as the addresses 
of the payload message as 
described in subclause 9.2.1. 


Fragments lieaders 

a) next header 

b) fragment Offset 

c) More fragment bit 

d) Identification 


Copied from IPv4 Protocol field 
Copied from the IPv4 Fragment 
offset field 

Copied from the value of the more 
fragment bit in the IPv4 flags field 
The value of this field should be 
mapped from the triple of the source 
address, destination address and 
IPv4 identification field of the 
incoming packet/fragments to a 
unique value for the source and 
destination address of the outgoing 
IPv6 packet/fragments. 



9.2.2.2 



Abnormal cases 



If IPv4 options are present in the IPv4 packet, they should be ignored i.e., there is no attempt to translate them. 
However, if an unexpired source route option is present then the packet shall instead be discarded, and an ICMPv4 
"destination unreachable/source route failed" Type 3/Code 5 error message shall be returned to the sender as defined in 
IETF RFC 792 [16]. 

When a translator receives the first fragment of a fragmented UDP IPv4 packet and the checksum field is zero the 
translator should drop the packet and generate a system management event specifying at least the IP addresses and port 
numbers in the packet. When it receives fragments other than the first it should silently drop the packet since there is no 
port information to log. 

When a translator receives an unfragmented UDP IPv4 packet and the checksum field is zero the translator shall 
compute the missing UDP checksum as part of translating the packet. Also, the translator should maintain a counter of 
how many UDP checksums are generated in this manner. 



9.2.2.3 



IPv6 to IPv4 



When the TrGW receives an IPv6 message the following codings shall be set in the IPv4 headers of the message sent to 
the IPv4 network. 

If there is no IPv6 fragment header, the IPv4 header fields shall be set as described in Table 3; 

If there is an IPv6 fragment header, the IPv4 header fields shall be set as described in Table 4. 
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Table 3: Derivation of IPv4 Header from IPv6 Header (no fragmentation) 



IPv4 field 


Value 


Version 


4 


Internet header length 


5 (No IPv4 options) 


Type of Service 


The default behaviour is that the 
value of the IPv4 field Type of 
service field is the value of the 
IPv6 Traffic class field (all 8 bits are 
copied). An implementation of a 
TrGW should also provide the ability 
to ignore the value of the IPv6 
Traffic Class and always set the 
IPv4 Type of Service field to zero. 


Total length 


The IPv4 Total Length field value is 
the IPv6 Payload length value plus 
the size of the IPv4 headers. 


Identification 


All bits are set to zero 


Flags 


The more fragment flag is set to 
zero. The Don"t fragment flag is set 
to one. 


Fragment offset 


Set to zero 


Time to live (TTL) 


The value of the field shall be set to 
the received IPv6 Hop Limit field 
value minus 1. 


Protocol 


The IPv4 field Protocol shall be set 
to the value of IPv6 field The next 
header value. 


Header checksum 


Computed once the IPv4 header 
has been created. 


Source Address 


Shall be handled as the addresses 
of the payload message as 
described in subclause 9.2.1. 


Destination Address 


Shall be handled as the addresses 
of the payload message as 
described in subclause 9.2.1. 



Table 4: Derivation of IPv4 Header from IPv6 Header (fragmentation) 



IPv4 field 


Value 


Version 


4 


Internet header length 


5 (No IPv4 options) 


Type of Service and Precedence: 


The default behaviour is that the 
value of the IPv4 field Type of 
service field is the value of the IPv6 
Traffic class field (all 8 bits are 
copied). An implementation of a 
TrGW should also provide the ability 
to ignore the value of the IPv6 
Traffic Class and always set the 
IPv4 Type of Service field to zero. 


Total length 


The IPv4 Total Length field value is 
the IPv6 Payload length value plus 
the size of the IPv4 headers minus 
8 for the Fragment header, 
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Identification 


The value of this field should be 
mapped from the triple of the source 
address, destination address and 
IPv6 fragmentation header field 
'identification' of the incoming 
packet/fragments to a unique value 
for the source and destination 
address of the outgoing IPv4 
packet/fragments. 


Flags 


The IPv4 IVIore Fragments flag is 
copied from the IPv6 M flag in the 
IPv6 Fragment header the IPv4. 
The Don't Fragments flag is set to 
zero allowing this packet to be 
fragmented by IPv4 routers. 


Time to live (TTL) 


The value of the field shall be set to 
the received IPv6 Hop Limit field 
value minus 1. 


Protocol 


The IPv4 field Protocol shall be set 
to the value of IPv6 field The next 
header value. 


Header checksum 


Computed once the IPv4 header 
has been created 


Source Address 


Shall be handled as the addresses 
of the payload message as 
described in subclause 9.2.1. 


Destination Address 


Shall be handled as the addresses 
of the payload message as 
described in subclause 9.2.1. 



9.2.2.4 



Abnormal cases 



If any of an IPv6 hop-by-hop options header, destination options header, or routing header with the Segments Left field 
equal to zero are present in the IPv6 packet, they are ignored i.e., there is no attempt to translate them. However, the 
Total Length field and the Protocol field shall be adjusted to "skip" these extension headers. 

If a routing header with a non-zero Segments Left field is present then the packet shall be translated, and an ICMPv6 
"parameter problem/ erroneous header field encountered" Type 4/Code error message as defined in IETF RFC 2463 
[17], with the Pointer field indicating the first byte of the Segments Left field should be returned to the sender. 

9.2.3 Fragmentation 

If the DF flag is not set and the IPv4 packet will result in an IPv6 packet larger than 1280 bytes the TrGW shall prior to 
transferring it in the IPv6 network: 

Add the fragment header to the message 

Fragment the IPv4 packets so that their length, excluding the IPv4 header, is at most 1232 bytes (1280 minus 40 
for the IPv6 header and 8 for the Fragment header). 

9.2.4 Abnormal cases 

As a part of decrementing the Time To Live /Hop Limit value and the TrGW discovers that the zero value is reached 
the TrGW shall send an ICMPv4/ICMPv6 message with the error 'time to live exceeded in transit' type 1 1 code as 
defined in IETF RFC 792 [16] and 'hop limit exceeded in transit' type 3 code as defined in IETF RFC 2463 [17]. 
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10 



IBCF - TrGW Interactions 



10.1 Overview 

10.1.1 General 

The present specification describes Ix signalling procedures and their interaction with SIP signalling in the control 
plane, and with user plane procedures. Each scenario or "use case" is described in a separate sub-clause within 10.2. 
3GPP TS 29.238 [25] maps these signalling procedures to H.248 messages and defines the required H.248 profile 
(which provides details of used packages and parameters). 

10.1.2 Network model 

Figure 10.1.2.1 shows the network model. The broken line represents the call control signalling. The dotted line 
represents the user plane. The IBCF uses one context with two terminations in the TrGW. 




Figure 10.1.2.1: Network model 

10.1.3 Example Call Flow 
10.1.3.1 Basic Procedures 

10.1.3.1.1 Call Establishment 

Figure 10.1.3.1.1.1 depicts the signalling flow for a call setup either from or toward an external network. 
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IBCF 



2. Use case X detected 
that needs TrGW 
functionality 



3. H.248ADDreq 

C= ?, T= ?, LAddr=?, LPort=?) 



4. Create outgoing termination T1 



7. SDPoffer(l='1o, Plo 



8. SDPanswe(IP1a, Pla; 



5. H.248 ADD resp. 
(C=C1,T=T1, 
LAddr=IPlo, LPort=Plo) 



A 



6. IVIodify SDP offer 



9. H.248 IVIOD req 
(C=CI,T=TI, 
RAddr=IPla, RPort=Pla) 



1 0. Configure Outgoing Termination T1 



11. H.248 IVIOD Resp 
C=C1,T=T1) 



12. H.248 ADD req 

C= CI, T= ?, LAddr=?, LPort=?, 

RAddr=IP2o, RPort=P20) 



1 3. Create incoming Termination T2 



14. H.248 ADD Resp 
C=C1,T=T2, 
LAddr=IP2a, LPort=P2a, 
RAddr=IPla, RPort=Pla) 



.lSDPoffer_(IP20j_P2p) 



15. Modify SDP answer 



Reserve 
TrGW 
Connection 
Point (, 
Change 
Through- 
Connection) 



Configure 
TrGW 
Connection 
Point (, 
Change 
Through- 
Connection) 



Reserve 
And 

Configure 
TrGW 
Connection 
Point (, 
Change 
Through- 
Connection) 



16. SDP answer(lp2a, P2a) 



1 . The IBCF receives an SDP offer In SIP signalling. 

2. The IBCF detects that one of the CS-TrGW functions is required, e.g. NAPT/NAT. 

3. The IBCF sends a H.248 ADD command to create the outgoing termination and to request resources to 
execute TrGW function. 

4. The TrGW creates the outgoing termination. 

5. The TrGW replies to IBCF with a H.248 Add reply command and provides the local address and port of the 
outgoing termination. 

6. The IBCF replaces the IP address inside the SDP using the information coming from TrGW. 

7. SDP offer is sent to the network at the outgoing side. 

8. SDP answer is received by IBCF. 
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9. The IBCF sends a H.248 MOD command to configure the outgoing termination with address and port 
information received in the SDP answer. 

10. The TrGW configures the outgoing termination. 

1 1 . The TrGW replies to IBCF with a H.248 MOD reply command. 

12. The IBCF sends a H.248 ADD command to create the incoming termination and to request resources to 
execute TrGW function. 

1 3. The TrGW creates the incoming termination. 

14. The TrGW replies to the IBCF with a H.248 Add reply command and provides the local address and port of 
the incoming termination.. 

Note: Steps 1 2 to 14 may also be executed after step 2. 

15. The IBCF replaces the IP address inside the SDP using the information coming from TrGW. 

16. SDP answer is sent to the network at the incoming side. 

Figure 10.1.3.1.1.1: IBCF and TrGW interaction at Call establishment. 

When creating the termination towards the IMS network or towards external networks, the IBCF may also indicate that 
the IP Interface Type is "MboIP". 

NOTE: Other values may be indicated by a CS-IBCF, as detailed in 3GPP TS 29.235 [29]. 

The IP Interface Type allows the TrGW to collect statistics per interface type associated with the RTP bearer 
termination. The provision of these statistics is outside of the scope of this specification. 



10.1.3.1.2 Call Release 

Figure 10.1.3.1.2.1 depicts the signalling flow for a call release. 



TrGW 



2. H.248 SUB req 

C=C1,T=T1) 



3. Destroy outgoing termination T1 



5. H.248 SUB req 

C=C1,T=T2) 



6. Destroy incoming termination T2 



IBCF 



4. H.248 SUB resp. 
(C=C1,T=T1) 



7. H.248 SUB resp. 
(C=C1, T=T2) 
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Termination 



Release 
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1 . The IBCF identifies tliat tlie call is to be release. Typically this will be by the receipt of a SIP BYE request. 

2. The IBCF sends a H.248 SUB command to release the outgoing termination 

3. The TrGW destroys the outgoing termination 

4. The TrGW replies to IBCF with a H.248 Sub reply command 

5. The IBCF sends a H.248 SUB command to release the incoming termination 

6. The TrGW destroys the incoming termination 

7. The TrGW replies to IBCF with a H.248 Sub reply command 

Note 1 : Steps 5 to 7 may also be executed before steps 2 to 4 or in parallel with steps 2 to 4. 
Note 2: Rather than releasing the two terminations separately, the IBCF may request the TrGW to release both 
terminations in a single request. 

Figure 10.1.3.1.2.1: IBCF and TrGW interaction at Call release 

10.2.0 Introduction 

The following functions shall be supported by the TrGW: 

- Gate Management: 

Opening/closing of gates; 

Remote source address filtering; 

Remote source port filtering; 
QoS packet marking (differentiated services); 
NAPT and IP Version Interworking; 
Bandwidth policing; 

- Hanging termination detection; 
IP Realm Indication. 

Additionally, the following functions may be supported by the TrGW: 
Resource allocation per flow; 
Detection and reporting of inactive media flows; 
IP Realm Availability. 

10.2 Main Functions supported at the Ix Interface 

1 0.2.1 IP Address and Port Conversion 

The IP Address and port conversion is configured by the standard Ix interactions at call setup depicted in Figure 
10. 1 .3. 1 . 1 . 1 . IP address and port conversion functionality documented in Clause 9. 

IP address and port conversion is mandatory every time a TrGW is inserted into the path for any reason to guarantee 
that all IP packets are routed through this entity. 

10.2.2 Gate Management 

The procedures in subclause A.7.1.2.2.3 of 3GPP TS 29.235 [29] are applicable. 

1 0.2.3 Handling of RTCP Streams 

The procedures in subclause A.7.1.2.2.7 of 3GPP TS 29.235 [29] are applicable. 
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10.2.4 IP Realm/Domain Indication 

Whenever requesting a new IP media-path (i.e. creation of IP bearer terminations), the TrGW may indicate the 
correspondent IP realm/domain to the TrGW. The TrGW shall assign the IP termination in the IP realm indicated. The 
same IP realm shall be applied to all media streams associated with the termination. The IP realm identifier shall not be 
changed after the initial assignment. 

A default IP realm may be configured such that if the TrGW has not received the IP realm identifier and the TrGW 
supports multiple IP realms then the default IP realm shall be used. 

10.2.5 Media Control 

The transcoding functionality, where the TrGW processes and possibly converts application / media data (like e.g. RTP 
payload) is optional for the TrGW and IBCF to support. 

The IBCF shall determine the TrGW transcoding capability through provisioning and MGW selection, outside the 
scope of this specification. 

IBCF procedures to offer transcoding in SIP/SDP signalUng are described in 3GPP TS 23.228 [8] and in 3GPP TS 
24.229 [1]. The IBCF shall only apply those transcoding procedures if an attached TrGW supports transcoding. For 
media with "RTP/SAVP" (see IETF RFC 371 1 [34]) or "RTP/SAVPF" (see IETF RFC 5124 [35]) as transport protocol, 
the IBCF shall not offer or apply transcoding. 

If the IBCF and available TrGW support transcoding, the IBCF may add codecs to a SDP offer within a SIP request. 

If the IBCF and available TrGW do not support transcoding, or if the IBCF chooses not to offer transcoding, the IBCF 
shall pass SDP offers without adding codecs to the SDP offer and the IBCF shall pass SDP answers without 
modification to the contained codecs. 

If the IBCF does not offer or apply transcoding procedures (as described above) but inserts the TrGW for any other 
reason, the IBCF shall either not signal media related information to the TrGW, or it shall signal the same media related 
information for all interconnected terminations (i.e. identical media configurations for the two connected H.248 stream 
endpoints). 

If the IBCF does not offer or apply transcoding it but signals media attributes to a TrGW that does not support 
transcoding without having seized the peer termination (see Figure 10.2.5.3, Step 3) the TrGW shall accept this request 
even though it cannot reserve any transcoding resources related to this media. When the peer Termination is seized and 
configured it shall be configured with the same media related sub-fields in the media descriptor as for the first 
Termination. If the selected codec is not the same as the codec configured at the first termination then this termination 
shall be modified before the peer termination is seized. 

NOTE 1 : The signalling of such codec related information by an IBCF to a TrGW not supporting transcoding is an 
implementation decision. 

NOTE 2: A TrGW not supporting transcoding can use such codec related information to learn that RTCP ports 
need to be reserved, and to derive information about packet size and frequency useful for internal 
resource reservation. 

If the IBCF and available TrGW support transcoding and the IBCF includes in a SDP offer additional codecs, the 
following procedures apply: 

The IBCF may seize a termination towards the terminating user, using the "Reserve TrGW Connection Point" 
procedure before sending an SDP offer with added codecs to the terminating user. The IBCF may signal media 
related information to the TrGW or omit media when adding the IP termination at this stage. 

NOTE 3: the signalling of media related information to a MGW requires that it reserve the indicated resources 
before returning a positive response to the H.248 command, by omitting media related information the 
TrGW does not need to reserve any associated resources at this stage. 

When the IBCF receives the SDP answer from the terminating user, the IBCF shall check if any of the codecs 
offered by the originating side are contained in the answer. 

If only the codecs inserted by the IBCF are contained in the answer, the IBCF shall configure the TrGW to 
transcode. If it previously performed a "Reserve TrGW Connection Point" procedure it shall configure the 
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TrGW using the "Configure TrGW Connection Point" procedure towards the termination on the terminating user 
side by supplying the media returned in the answer from the terminating user, otherwise it shall perform a 
"Reserve and Configure TrGW Connection Point" procedure. Within those procedures, the IBCF shall supply 
the media returned in the answer from the terminating user. If the IBCF seized the teremination only at this point 
in time, it shall send the IP address and port information received from the TrGW in the acknowledment to the 
"Reserve and Configure TrGW Connection Point" procedure towards the terminating user in a new SDP offer. 
The IBCF shall perform the "Reserve and Configure TrGW Connection Point" procedure towards the 
termination on the originating user side, supplying the preferred media offered by the originating side. 

If the returned SDP contains media offered by the originating user no transcoding at the TrGW is required. If 
the IBCF previously performed the "Reserve TrGW Connection Point" procedure the IBCF shall configure the 
TrGW accordingly by either either supplying the same media related information for all interconnected 
terminations or by omitting the media related information. 

Some basic use cases are depicted in figures 10.2.5.1 10.2.5.2, and 10.2.5.3. 
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1 . The IBCF receives an SDP offer in SIP signalling. 

2. The IBCF adds additional codecs to the subsequent SDP offer, giving priority to those offered by the 
preceding node/network. 

3. In this example the IBCF seizes a TrGW prior to sending the new SDP offer; as this scenario is preparing 
for a possible transcoding in the TrGW then a TrGW supporting media shall be seized. The IBCF sends a 
H.248 ADD command to create the outgoing termination and to request IP resources to execute TrGW 
function. As no media transcoding is yet known to be needed this may be indicated by omitting media 
related sub-fields in the media descriptor (i.e. signalling "-"). Alternatively the preferred codec (e.g. Codec 
1 ) may be signalled in order to reserve this resource in the event that transcoding was required. 

4. The TrGW creates the outgoing termination. 
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5. The TrGW replies to IBCF with a H.248 Add reply command and provides the local address and port of the 
outgoing termination. 

6. The IBCF replaces the IP address inside the SDP using the information coming from TrGW 

7. The IBCF forwards the new offer to the succeeding node. 8. SDP answer is received by IBCF. In this 
example the coded received in the original SDP offer in step1 has been selected by the succeeding 
network/terminating UE and the IBCF determines that transcoding is not required. 

9. The IBCF sends a H.248 MOD command to configure the outgoing termination with address and port 
information received in the SDP answer. As no media transcoding is needed this may be indicated by 
omitting media related sub-fields in the media descriptor (i.e. signalling "-"). Alternatively the selected 
codec (Codec 1) may be signalled 

10. The TrGW configures the outgoing termination. 

1 1 . The TrGW replies to IBCF with a H.248 MOD reply command. 

12. The IBCF sends a H.248 ADD command to create the incoming termination to configure this termination 
with remote address and port information and to request resources to execute TrGW function. As no 
media transcoding is needed this may be indicated by omitting media related sub-fields in the media 
descriptor (i.e. signalling "-"). Alternatively the selected codec received in step 8 (Codec 1) may be 
signalled 

1 3. The TrGW creates the incoming termination. 

14. The TrGW replies to the IBCF with a H.248 Add reply command and provides the local address and port of 
the incoming termination. 

15. The IBCF replaces the IP address inside the SDP using the information coming from TrGW. 

16. SDP answer is sent to the network at the incoming side. 

Figure 10.2.5.1 : IBCF and TrGW interaction when the IBCF offers additional codecs but no 
transcoding is required, and the TrGW is seized in advance. 
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(C=? 
Local 




1_ SDP offer_(IP20j.P2p, 

, codecT, codec2) 

2. IBCF supports transcoding 
and supports additional 
codecs 



248 ADD req 

T= ?, LAddr=?, LPort=?, 

Resources="-" or coded or codec 2 or 



codec 3) 



4. Create outgoing termination T1 



DPoffer(IP1o,P1o, coded 



8. SDP answer (IP1 a. 



5. H.248 ADD resp. 
(C=C1,T=T1, 
LAddr=IPlo, LPort=Plo) 



Reserve 
TrGW 
Connection 
Point 



codec 2, codec 3) 
P1a, codec3) 



6. IVIodify SDP offer 



9. H.248 IVIOD req 
(C=C1,T=T1, 
RAddr=IPla, RPort=Pla, 
Local Resources= codec3 
Remote Resources= codec3) 



1 0. Configure Outgoing Termination T1 



11. H.248 IVIOD Resp 
C=C1,T=T1) 
► 

12. H.248 ADD req 

C= CI, T= ?, LAddr=?, LPort=?, 
RAddr=IP2o, RPort=P2o, 
Local Resources=codecl orcodec2, 
Remote Resources=codecl or codec: 



1 3. Create incoming Termination T2 



14. H.248 ADD Resp 
C= CI, T= T2, 
LAddr=IP2a, LPort=P2a, 
RAddr=IP2o, RPort=P2o) 



Configure 
TrGW 
Connection 
Point 



Reserve 

And 

Configure 

TrGW 

Connection 

Point 



15. IVIodify SDP answer 



16. SDP answer(lp2a, P2a, 
. codsci, or_codec_2j_ _^ 



1 . The IBCF receives an SDP offer in SIP signalling. 

2. Tlie IBCF adds additional codecs to the subsequent SDP offer, giving priority to those offered by the 
preceding node/network. 

3. In this example the IBCF seizes a TrGW prior to sending the new SDP offer; as this scenario is preparing 
for a possible transcoding in the TrGW then a TrGW supporting media shall be seized. The IBCF sends a 
H.248 ADD command to create the outgoing termination and to request IP resources to execute TrGW 
function. As no media transcoding is yet known to be needed this may be indicated by omitting media 
related sub-fields in the media descriptor (i.e. signalling "-"). Alternatively the preferred codec (e.g. Codec 
1 ) may be signalled in order to reserve this resource in the event that transcoding was required. 

4. The TrGW creates the outgoing termination. 
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5. The TrGW replies to IBCF with a H.248 Add reply command and provides the local address and port of the 
outgoing termination. 

6. The IBCF replaces the IP address inside the SDP using the information coming from TrGW. 

7. The IBCF forwards the new offer to the succeeding node. 

8. The SDP answer is received by IBCF. In this example the codecS added by the IBCF to the SDP offer has 
been selected. Transcoding is therefore required. 

9. The IBCF sends a H.248 MOD command to configure the outgoing termination with address and port 
information received in the SDP answer and the selected media attibutes (codec 3). 

10. The TrGW configures the outgoing termination. 

1 1 . The TrGW replies to IBCF with a H.248 IVIOD reply command. 

12. The IBCF sends a H.248 ADD command to create the incoming termination to configure this termination 
with remote address and port information and to request resources to execute TrGW function. As media 
transcoding is required it indicates this explicitly with a codec selected by the IBCF for the incoming 
termination from the offered codec{s) received in step1 . 

13. The TrGW creates the incoming termination. 

14. The TrGW replies to the IBCF with a H.248 Add reply command and provides the local address and port of 
the incoming termination.. 

15. The IBCF replaces the IP address inside the SDP using the information coming from TrGW and replaces 
the codec with the codec it selected for the incoming termination. 

16. SDP answer is sent to the network at the incoming side. 

Figure 10.2.5.2: IBCF and TrGW interaction when IBCF offers additional codecs and transcoding is 

required, and the TrGW is seized in advance. 
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5. H.248 ADD resp. 
(C=C1,T=T1, 
LAddr=IPlo, LPort=Plo) 



A 



6. IVIodify SDP offer 



9. H.248 IVIOD req 
(C=C1,T=T1, 
RAddr=IPla, RPort=Pla, 
Local Resources="-" or coded 
Remote Resources="-" or coded) 



1 0. Configure Outgoing Termination T1 



11. H.248 IVIOD Resp 
C=C1,T=T1) 
► 

12. H.248 ADD req 

C= CI, T= ?, LAddr=?, LPort=?, 
RAddr=IP2o, RPort=P2o, 
Local Resources="-" or coded, 
Remote Resources="-" or coded) 



1 3. Create incoming Termination T2 



14. H.248 ADD Resp 
C= CI, T= T2, 
LAddr=IP2a, LPort=P2a, 
RAddr=IP2o, RPort=P2o) 



Reserve 
TrGW 
Connection 
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Configure 
TrGW 
Connection 
Point 



Reserve 

And 

Configure 

TrGW 

Connection 

Point 



15. IVIodify SDP answer 



16. SDP answer(lp2a, P2a, 
. codecj ]_ ^ 



1 . The IBGF receives an SDP offer in SIP signalling. 

2. The IBGF requires a TrGW for another use case but does not offer transcoding. 

3. The IBGF sends a H.248 ADD command to create the outgoing termination and to request IP resources to 
execute TrGW function. As no media transcoding is required this may be indicated by signalling "-". 
Alternatively the any codec (e.g. Codec 1) can be signalled. If the IBGF selects a TrGW that does not 
support transcoding, the IBGF may signal media related sub-fields in the media descriptor to the TrGW if 
the TrGW supports media encoding. The TrGW shall accept the ADD request even though it cannot 
reserve any transcoding resources for the indicated media. 

4. The TrGW creates the outgoing termination. 



ETSI 



3GPP TS 29.1 62 version 10.1.0 Release 1 30 ETSI TS 1 29 1 62 VI 0.1 .0 (201 1 -04) 

5. The TrGW replies to IBCF with a H.248 Add reply command and provides the local address and port of the 
outgoing termination. 

6. The IBCF replaces the IP address inside the SDP using the information coming from TrGW . 

7. The IBCF forwards the new offer to the succeeding node. 

8. The SDP answer is received by IBCF. In this example the coded received in the original SDP offer in 
step1 has been selected. 

9. The IBCF sends a H.248 MOD command to configure the outgoing termination with address and port 
information. As no media transcoding is needed this may be indicated by signalling "-" .Alternatively the 
selected codec (Codec 1) can be signalled. 

10. The TrGW configures the outgoing termination. 

1 1 . The TrGW replies to IBCF with a H.248 MOD reply command. 

12. The IBCF sends a H.248 ADD command to create the incoming termination to configure this termination 
with remote address and port information and to request resources to execute TrGW function. As no 
media transcoding is needed this may be indicated by signalling "-" .Alternatively media related sub-fields 
in the media descriptor for the codec indicated to the incoming termination may be signalled (e.g. the 
selected codec received in step 8 (Codec 1). 

1 3. The TrGW creates the incoming termination. 

14. The TrGW replies to the IBCF with a H.248 Add reply command and provides the local address and port of 
the incoming termination. 

15. The IBCF replaces the IP address inside the SDP answer using the information coming from TrGW. 

16. SDP answer is sent to the network at the incoming side. 

Figure 10.2.5.3: IBCF and TrGW interaction when IBCF does not offer transcoding 

10.2.6 Media Inactivity Detection 

The procedures in subclause A.7.1.2.2.6 of 3GPP TS 29.235 [29] are applicable. 

1 0.2.7 QoS Packet Marking 

The procedures in subclause A.7.1.2.2.4 of 3GPP TS 29.235 [29] are applicable. 

Those procedures relate to Diffserv code point marking as described in IETF RFC 2474 [31] 

10.2.8 Hanging Termination Detection 

The procedures in subclause A.7.1.2.2.2 of 3GPP TS 29.235 [29] are applicable. 

10.2.9 Traffic Policing 

The procedures in subclause A.7.1.2.2.8 of 3GPP TS 29.235 [29] are applicable. 

1 0.2.1 IMS end-to-end media plane security 

An IBCF and a TrGW may support the end-to-end IMS media plane security as specified in 3GPP TS 33.328 [32]. If 
supported, the IBCF shall use the following procedures. 

If the IBCF receives SDP containing media lines with "RTP/SAVP" (see IETF RFC 3711 [34]) or "RTP/SAVPF" (see 
IETF RFC 5124 [35]) as transport protocol, the IBCF shall: 

forward the SDP with unmodified transport protocol for those media lines; 

apply the procedures to not offer or apply transcoding defined in subclause 10.2.5; and 

- provide "RTP/SAVP" or "RTP/SAVPF", as received in the SDP, to the TrGW as transport protocol for all 
related terminations, and not provide media related information to these terminations, to configure the TrGW to 
pass media and possibly associated RTCP control flows and not to reserve any resources. 
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Note: RTP/SAVP or SAVPF are provided to the TrGW even though it does not reserve any resources for this as 
such, but this is needed in order to allocate dual ports to support RTCP flows. These are also controlled as 
described in subclause 10.2.3. For "RTP/SAVP" or "RTP/SAVPF", RTCP will be encrypted and can not 
be interpreted by the TrGW. Media information is also meaningless as encryption will modify the 
properties of the media streams, t 

If the IBCF receives SDP containing SDES SDP attribute(s) according to IETF RFC 4568 [33], it shall forward the SDP 
with unmodified SDES SDP attribute(s), but shall not provide the SDES SDP attribute(s) to the TrGW. 

10.2.11 Through-Connection 

The procedures in subclause A.7.1.2.2.9 of 3GPP TS 29.235 [29] are apphcable. 

10.2.12 Emergency Call 

The procedures in subclause A.7. 1 .2.2. 10 of 3GPP TS 29.235 [29] are applicable. 

1 0.2.1 3 Explicit Congestion Notification Support 

10.2.13.1 General 

An IBCF and TrGW may support Multimedia Telephony using ExpUcit Congestion Notification (ECN) according to 
IETF RFC 3168 [37], and may act as an ECN endpoint to enable ECN with a local ECN-capable terminal within a local 
network that properly handles ECN-marked packets. 

Editor's Note: there may be a requirement to support RTCP. This could be considered coupled to the RTP 
topology and thus the support needs to be considered further. 

1 0.2.1 3.2 Incoming SDP Offer with ECN 

If the IBCF receives a SDP offer containing the "a=ecn-capable-rtp" attribute (see IETF draft-ietf-avtcore-ecn-for-rtp 
[38]), then if all of the following statements are true: 

a) the IBCF supports ECN according to 3GPP TS 26.114 [36]; 

b) the TrGW supports ECN according to 3GPP TS 26.114 [36]; 

c) the IBCF knows (via configuration) that the succeeding network supports ECN according to 3GPP TS 26.1 14 
[36]; 

d) the IBCF does not insert any transcoding; 

then the IBCF shall 

if the "ecn-capable-rtp" attribute includes both the "ice" initialisation method and other initialisation methods, 
remove the "ice" initialisation method from the "ecn-capable-rtp" attribute and forward the attribute with this 
modification in the outgoing SDP offer; 

if the "ecn-capable-rtp" attribute only includes the "ice" initialisation method, remove the "ecn-capable-rtp" 
attribute, any "rtcp-fb" attribute with the "nack" feedback parameter and the "ecn" feedback parameter value, and 
any "ecn-sum" parameter within a "rtcp-xr" attribute from the outgoing SDP offer; 

if the "ecn-capable-rtp" attribute did not includes the "ice" initialisation method, forward the unmodified "ecn- 
capable-rtp" attribute within the outgoing SDP Offer; and 

if the IBCF includes the "ecn-capable-rtp" attribute within the outgoing SDP offer, forward the SDP offer 
containing ECN parameters to the succeeding network. 

Otherwise the IBCF shall remove the "ecn-capable-rtp" attribute, any "rtcp-fb" attribute with the "nack" feedback 
parameter and the "ecn" feedback parameter value, and any "ecn-sum" parameter within an "rtcp-xr" attribute from the 
outgoing SDP offer. 
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If the IBCF forwarded the SDP offer containing the "a=ecn-capable-rtp" attribute and receives a SDP answer also 
containing the "a=ecn-capable-rtp" attribute (the reception of the attribute indicates a successful ECN negotiation) then 
the IBCFshall forward the SDP answer to its preceding node and shall indicate to the TrGW that it shall transfer ECN 
bits in IP header transparently. 

If the IBCF forwarded the SDP offer containing the "a=ecn-capable-rtp" attribute and receives the SDP answer without 
the "a=ecn-capable-rtp" attribute and the TrGW supports at least some of the initialisation methods within the "a=ecn- 
capable-rtp" attribute in the previously received SDP offer 

NOTE: Only the "leap" initialisation method is supported over the Ix interface in this release. 

the IBCF shall 

act as an end point for ECN; 

select an initialisation method supported by the TrGW; 

determine if application specific feedback or ECN feedback messages shall be used, taking into account whether 
the TrGW supports ECN feedback messages, and the negotiation procedures in 3GPP TS 26.1 14 [104]; 

determine if ECN XR summary reports can be used, taking into account whether they are supported at the IM- 
and the negotiation procedures in 3GPP TS 26.114 [104]; 

return a SDP answer according to 3GPP TS 26.1 14 [104] and the capabilities of the TrGW, containing the ECN 
attribute "a=ecn-capable-rtp"; and 

indicate to the TrGW that it shall apply the ECN procedures (according to 3GPP TS 26.1 14 [104]) and act as an 
ECT endpoint. 

If the IBCF receives the SDP offer containing the "a=ecn-capable-rtp" attribute and bullets a) and b) above are satisfied 
but if bullet c) or d) or both are not met then the IBCF shall remove ECN related attributes before forwarding the SDP 
offer. If the TrGW supports at least some of the initialisation methods offered within the "a=ecn-capable-rtp" attribute, 

NOTE: Only the "leap" initialisation method is supported over the Ix interface in this release. 

the IBCF shall 

act as an end point for ECN; 

select an initialisation method supported by the TrGW; 

determine if application specific feedback or ECN feedback messages shall be used, taking into account whether 
the IM-MGW supports ECN feedback messages, and the negotiation procedures in 3GPP TS 26. 1 14 [104]; 

determine if ECN XR summary reports can be used, taking into account whether they are supported at the IM- 
and the negotiation procedures in 3GPP TS 26.1 14 [104]; 

return a SDP answer according to 3GPP TS 26.114 [104] and the capabilities of the TrGW, containing the 
"a=ecn-capable-rtp" attribute; and 

indicate to the TrGW that it shall apply the ECN procedures (according to 3GPP TS 26.1 14 [104]) and act as an 
ECT endpoint. 

1 0.2.1 3.3 Incoming SDP Offer without ECN 

If the IBCF receives a SDP offer without the "a=ecn-capable-rtp" attribute then if all of the following statements are 
true: 

a) the IBCF supports ECN according to 3GPP TS 26.1 14 [36]; 

b) the TrGW supports ECN according to 3GPP TS 26.1 14 [36]; 

c) the IBCF knows (via configuration) that the succeeding network supports ECN according to 3GPP TS 26.1 14 
[36]; 
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the IBCF may include the "a=ecn-capable-rtp" attribute in the offer it forwards towards the succeeding node, indicating 
the related capabilities of the TrGW. 

If the IBCF inserted ECN attributes in the SDP offer and receives a SDP answer containing the "a=ecn-capable-rtp" 
attribute the IBCF shall act as an endpoint and shall return the SDP answer to the preceding node removing the "a=ecn- 
capable-rtp" attribute, any "rtcp-fb" attribute with the "nack" feedback parameter and the "ecn" feedback parameter 
value, and any "ecn-sum" parameter within a "rtcp-xr" attribute, and shall indicate to the TrGW that it shall apply the 
ECN procedures according to 3GPP TS 26.1 14 [36] and act as an ECT endpoint. 

If the IBCF inserted the "a=ecn-capable-rtp" attribute in the SDP offer and receives the SDP answer without the "a=ecn- 
capable-rtp" attribute the IBCF shall continue the call without any ECN active. 

1 0.2.1 3.3a Detection of ECN failures by TrGW 

If the TrGW acts as ECN endpoint and detects an ECN-related error case, for example non-ECT in the received packets 
when ECT(O) was expected or detecting a very high packet loss rate when ECN is used, the TrGW shall notify the 
IBCF. The IBCF should then initiate a session re-negotiation to disable ECN. 

1 0.2.1 3.4 Interworking with non-3GPP EON IP terminal 

Editor's Note: 3GPP TS 23.228 indicates that interworking to non-3GPP ECN IP terminal is permitted but TS 
26. 1 14 requirements need to be further analysed, not yet covered in this TS. 

TS 26. 114 states: "An MTSI MGW can also be used to enable ECN end-to-end if the remote client 
uses ECN in a different way than what is described in this specification for the MTSI client in 
terminal, e.g. if the remote client only supports probing for the ECN initiation phase or it needs 
the ECN feedback." 

1 0.2.1 3.5 Message sequence chart 

10.2.13.5.1 ECN Support Requested (ECN Endpoint) 

Figure 10.2.13.5.1.1 shows the message sequence chart example for requesting Explicit Congestion Notification. 



IBCF 



Context(Cx; 
Context(Cx; 



H.248:ADD.req [Termination 

XJransport = RTP/AVPF, 

ECN=endpoint, 

{Notify_ECN_Error}] 



H.248:ADD.resp[Terniination X] 



TrGW 



Reserve IMS 

Connection Point and 

Configure Remote 

Resources 

indicates Transport and 

requests IIVI-IVIGWto 

support explicit congestion 

notification 



Figure 10.2.13.5.1.1: Procedure to Request ECN 

Editor's Note: Additional attributes or properties may need to be included in this interface. 

Upon receipt of a request to apply Explicit Congestion Notification the TrGW shall set the ECN field of the IP header in 
accordance with 3GPP TS 26.1 14 [36] when sending any data packets. 

Upon receipt of any IP headers indicating ECN Congestion Experienced (ECN-CE) the TrGW shall trigger rate 
adaptation in accordance with 3GPP TS 26.1 14 [36]. 
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NOTE: ECN requires the IBCF to configure the TrGW with all media attributes to allow rate adaptation even if 
no transcoding is required/supported in the TrGW. 

10.2.13.5.2 ECN Active Indicated (ECN Transparent) 

Figure 10.2.13.5.2.1 shows the message sequence chart example for indicating Explicit Congestion Notification. 



IBCF 



Context(Cx; 
Context(Cx; 



TrGW 



H.248:ADD.req[Termination 

X.Transport = RTP/AVPF, ECN ■- 

transparent] 



H.248:ADD.resp[Termination X] 



Reserve IMS 

Connection Point and 

Configure Remote 

Resources 

Indicates Transport and 

requests IM-MGW to 

support explicit congestion 

notification transparently 



Figure 10.2.13.5.2.1: Procedure to indicate ECN negotiated 

Editor's Note: Additional attributes or properties may need to be included in this interface. 

Upon receipt of the indication that ECN has been negotiated the TrGW shall forward IP packets with ECN bits set 
unmodified. 

10.2.13.5.3 ECN Error Indication (ECN Endpoint) 

Figure 10.2.13.5.3.1 shows the message sequence chart example for an ECN Error Event. 



IBCF 



Context(Cx; 
Context(Cx; 



TrGW 



H.248:NOTIFY.req(ECN Error) 
[Termination =x, cause=ecn_cause] 



H.248:NOTiFYTesp(ECN 
Error)[Termination x] 



Report ECN Error 

Indicates to MRFC if an 

error has occurred due to 

ECN. 



Figure 10.2.13.5.3.1: Procedure to Report ECN Error 

When the IBCF receives a Notification indicating that an error has occurred it may trigger a new SDP offer to disable 
ECN. 

10.2.14 Optimal Media Routeing 

An IBCF may support optimal media routeing procedures, as defined in 3GPP TS 29.079 [39]. 
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3GPP TS 29.079 specifies that "secondary media resources" may be allocated in addition to "primary media resources". 
If cotrolled by an IBCF, such primary or secondary media resources are TrGWs controlled over the Ix interface with 
procedures specified in the present specification. 

If the IBCF applies optimal media routeing procedures, the following modifications to the procedures within the present 
specification are applicable: 

- Under conditions specified in 3GPP TS 29.079 [39], the IBCF uses information from OMR related SDP 
attributes as remote connection and port information that is provided towards the TrGW within the call 
establishment procedures in clause 10.1.3.1.1. 

Under conditions specified in 3GPP TS 29.079 [39], the IBCF encapsulates local addess and port information, as 
received from the TrGW within the call establishment procedures in clause 10.1.3.1.1, in OMR related SDP 
attributes. 

- Under conditions specified in 3GPP TS 29.079 [39], the IBCF uses information from OMR related SDP 
attributes as codec information that is provided towards the TrGW within the media control procedures in clause 
10.2.5. 

3GPP TS 29.079 [39] specifies OMR-specific events that trigger the call release procedures in clause 10.1.3.1.2. 

10.3 VOID 

10.4 Procedures 

10.4.1 Call related Procedures 

1 0.4.1 .1 Reserve TrGW Connection Point 

This procedure is used to reserve an termination at the TrGW. 
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Table 10.4.1.1.1 : Reserve TrGW Connection Point 



Procedure 


Initiated 


Information 
element name 


Information 
element 
required 


Information element description 


Reserve TrGW 


IBCF 


Context/Context 


M 


This information element indicates the 


Connection Point 




Request 




existing context or requests a new 
context for the bearer termination. 


Emergency Call 





This information element identifies the 






Indicator 




call as emergency call that requires a 
preferential handling. 


Termination 


M 


This information element requests a new 






Request 




termination for the bearer to be 
established. 


IP Interface 





This information element specifies the 










type of external interface to be used for 










the IP termination (e.g. MbolP). 


Local IP Resources 





This information element indicates the 










resource{s) (e.g. codec, auxiliary payload 










types) for which the TrGW shall be 










prepared to receive user data. IVIay be 










excluded (i.e. "-" is used in SDP m-line) if 










no transcoding or other media related 










functions are required. 


ReserveValue 


C 


This information element indicates if 










multiple local resources are to be 










reserved. 










This information element shall be 










included if a speech codec and auxiliary 










payload types are configured. 


Local Connection 


M 


This information element requests an IP 






Address Request 




address and port number on the TrGW 
that the remote end can send user plane 
data to. 


Remote Source 





This information element indicates that 






Address Filtering 




remote source address filtering is 
required. 


Remote Source 


C 


This information element provides 






Address IVIask 




information on the valid remote source 
addresses. This may be included if 
remote source address filtering is 
included. It shall not be included if 
remote source address filtering is not 
included. 


Remote Source 





This information element indicates that 






Port Filtering 




remote source port filtering is required. 


Remote Source 


C 


This information element identifies the 






Port 




valid remote source port. This may be 
included if remote source port filtering is 
included. It shall not be included if 
remote source port filtering is not 
included. (N0TE1) 


Remote Source 


C 


This information element identifies a 






Port Range 




range of valid remote source ports. This 
may be included if remote source port 
filtering is included. It shall not be 
included if remote source port filtering is 
not included. (NOTE 1) 


RTCP handling 





Indicates whether or not the TrGW shall 










reserve a port for an RTCP flow. 


Notify termination 


M 


This information element requests 






heartbeat 




termination heartbeat indications. 


Notify Released 





This information element requests a 






Bearer 




notification of a released bearer. 
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DiffServ Code Point 



DiffServ Tagging 
Betiaviour 



IP Realm Identifier 



Traffic Policing 
Required 



Peak Data Rate 



Sustainable Data 
Rate 



Delay Variation 
Tolerance 



Maximum Burst 
Size 



IVIedia Inactivity 
Detection Required 



Inactivity Detection 
Time 



Inactivity Detection 
Direction 



ECN Control 



Notify ECN Error 
Event 



O 



O 



O 



O 



O 



O 



O 



O 



O 



O 



This information element indicates a 
specific DiffServ code point to be used in 
the IP header in packets sent on the IP 
termination. 



This information element indicates 
whether the Diffserv code point in thelP 
header in packets sent on the IP 
termination should be copied from the 
received value or set to a specific value. 



This information element indicates the IP 
realm of the IP termination. 



This information element indicates that 
policing of the media flow is required. 



This information element may be present 
if Policing is required and specifies the 
permissible peak data rate for a media 
stream. (NOTE 2) 



This information element may be present 
if Policing is required and specifies the 
permissible sustainable data rate for a 
media stream. (NOTE 2) 



This information element may be present 
if Policing on Peak Data Rate is required 
and specifies the maximum expected 
delay variation tolerance for the 
corresponding media stream. 



This information element shall be present 
if Policing on Sustainable Data Rate is 
required and specifies the maximum 
expected burst size for the 
corresponding media stream. 



This information element indicates that 
detection of inactive media flows is 
required. 



This information element may be present 
if Inactive Media Detection is required 
and specifies the Inactivity Detection 
time. 



This information element may be present 
if Inactive Media Detection is required 
and specifies the Inactivity Detection 
direction. 



This information element either requests 
the TrGW to apply ECN procedures and 
IP header setting, and thus to act as an 
ECN endpoint, or indicates that ECN is 
active and ECN bits shall be passed 
transparently. 



This requests a notification if an error 
occurs due to ECN. It shall only be 
supplied if ECN Control is supplied with 
ECN endpoint value. 



Reserve TrGW 

Connection Point 

Ack 



TrGW 



Context 



M 



This information element indicates the 
context where the command was 
executed. 



Termination 



M 



This information element indicates the 
termination where the command was 
executed. 



Local IP Resources 



This information element indicates the 
resources that the TrGW has reserved to 
receive the user plane data from the 
remote peer. This IE shall be present if it 
was contained in the request. If the IE 
was not contained in the request, it may 
be present in the reply. 
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Local Connection 
Address 



M 



This information element indicates the IP 
address and port on the TrGW that shall 
receive user plane data from the remote 
peer. 



NOTE 1 : Remote Source Port and Remote Source Port Range are mutually exclusive. 
NOTE 2: At least one of these lEs shall be present when policing is required. 



Editor's Note: Details of ECN control IE are ffs, e.g. if this IE will be spilt in several information elements. 

1 0.4.1 .2 Configure TrGW Connection Point 

This procedure is used to configure or reconfigure an termination at the TrGW. 
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Table 10.4.1.2.1 : Configure TrGW Connection Point Procedure 



Procedure 


Initiated 


Information 
element name 


Information 
element 
required 


Information element description 


Configure TrGW 


IBCF 


Context 


M 


This information element indicates the 


Connection Point 








existing context. 


Termination 


M 


This information element indicates the 










existing bearer termination. 


IP Interface 





This information element specifies the 










type of external interface to be used for 










the IP termination (e.g. MbolP). 


Local IP Resources 





This information element indicates the 










resources (e.g. codec, auxiliary payload 










types) that the TrGW may use on the 










reception of user plane data. 










If Local Connection Address is supplied 










may be excluded (i.e. "-" is used in SDP 










m-line) if no transcoding or other media 










related functions are required. 


Remote IP 





This information element indicates the 






Resources 




resources (e.g. codec, auxiliary payload 
types) that the TrGW may send user 
plane data to. 

If Remote Connection Address is 
supplied may be excluded (i.e. "-" is used 
in SDP m-line) if no transcoding or other 
media related functions are required. 


Local Connection 





This information element indicates the IP 






Address 




address and port on the TrGW that the 
remote peer can send user plane data to. 


Remote 





This information element indicates the IP 






Connection 




address and port that the TrGW can 






Address 




send user plane data to. 


Reserve Value 


C 


This information element indicates if 










multiple resources are to be reserved. 










This information element shall be 










included if a speech codec and auxiliary 










payload types are configured. 


Remote Source 





This information element indicates that 






Address Filtering 




remote source address filtering is 
required. 


Remote Source 


C 


This information element provides 






Address IVIask 




information on the valid remote source 
addresses. This may be included if 
remote source address filtering is 
included. It shall not be included if 
remote source address filtering is not 
included. 


Remote Source 





This information element Indicates that 






Port Filtering 




remote source port filtering is required. 


Remote Source 


C 


This information element identifies the 






Port 




valid remote source port. This may be 
included if remote source port filtering is 
included. It shall not be included if 
remote source port filtering is not 
included. (N0TE1) 


Remote Source 


C 


This information element identifies a 






Port Range 




range of valid remote source ports. This 
may be included if remote source port 
filtering is included. It shall not be 
included if remote source port filtering is 
not included. (NOTE 1) 


RTCP handling 





Indicates whether or not the TrGW shall 










reserve a port for an RTCP flow 


Traffic Policing 





This information element indicates that 






Required 




policing of the media flow is required. 
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Peak Data Rate 



Sustainable Data 
Rate 



Delay Variation 
Tolerance 



Maximum Burst 
Size 



DiffServ Code Point 



DiffServ Tagging 
Behaviour 



Media Inactivity 
Detection Required 



Inactivity Detection 
Time 



Inactivity Detection 
Direction 



ECN Control 



Notify ECN Error 
Event 



O 



O 



O 



O 



O 



O 



O 



O 



This information element may be present 
if Policing is required and specifies the 
permissible peak data rate for a media 
stream. (NOTE 2) 



This information element may be present 
if Policing is required and specifies the 
permissible sustainable data rate for a 
media stream. (NOTE 2) 



This information element may be present 
if Policing on Peak Data Rate is required 
and specifies the maximum expected 
delay variation tolerance for the 
corresponding media stream. 



This information element shall be present 
if Policing on Sustainable Data Rate is 
required and specifies the maximum 
expected burst size for the 
corresponding media stream. 



This information element indicates a 
specific DiffServ code point to be used in 
the IP header in packets sent on the IP 
termination. 



This information element indicates 
whether the Diffserv code point in thelP 
header in packets sent on the IP 
termination should be copied from the 
received value or set to a specific value. 



This information element indicates that 
detection of inactive media flows is 
required. 



This information element may be present 
if Inactive Media Detection is required 
and specifies the Inactivity Detection 
time. 



This information element may be present 
if Inactive Media Detection is required 
and specifies the Inactivity Detection 
direction. 



This information element either requests 
the TrGW to apply ECN procedures and 
IP header settings, and thus to act as an 
ECN endpoint, or indicates that ECN is 
active and ECN bits shall be passed 
transparently. 



This requests a notification if an error 
occurs due to ECN. It shall only be 
supplied if ECN Control is supplied with 
ECN endpoint value. 



Configure TrGW 
Connection Point 
Ack 



TrGW 



Context 



M 



This information element indicates the 
context where the command was 
executed. 



Termination 



M 



This information element indicates the 
termination where the command was 
executed. 



Local IP Resources 



O 



This information element indicates the 
resources that the TrGW has reserved to 
receive the user plane data from the far 
end. 



Remote IP 
Resources 



O 



This information element indicates the 
resource (i.e. codec) that the TrGW shall 
use to send user data to. May be present 
only if corresponding IE is present in the 
request. 



Local Connection 
Address 



O 



This information element indicates the IP 
address and port on the TrGW that the 
remote end can send user plane data to. 
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Remote 

Connection 

Address 



O 



This information element indicates the IP 
address and port that the TrGW can 
send user plane data to. May be present 
only if corresponding IE is present in the 
request. 



NOTE 1 : Remote Source Port and Remote Source Port Range are mutually exclusive. 
NOTE 2: At least one of these lEs shall be present when policing is required. 



Editor's Note; Details of ECN control IE are ffs, e.g. if this IE will be spilt in several information elements. 

10.4.1 .3 Reserve and Configure TrGW Connection Point 

This procedure is used to reserve and configure multimedia-processing resources for a termination at the TrGW. 
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Table 10.4.1.3.1 : Reserve and Configure TrGW Connection Point 



Procedure 



Initiated 



Information element 
name 



Information 
element 
required 



Information element description 



Reserve and 
Configure TrGW 
Connection Point 



IBCF 



Context/Context 
Request 



Emergency Call 
Indicator 



Termination/ 
Termination Request 



IP Interface 



Local IP Resources 



Remote IP Resources 



Reserve Value 



Local Connection 
Address request 



Remote Connection 
Address 



Remote Source 
Address Filtering 



Remote Source 
Address IVIask 



Remote Source Port 
Filtering 



Remote Source Port 



Remote Source Port 
Range 



RTCP handling 



Notify termination 
heartbeat 



IVI 



This information element indicates the 
existing context or requests a new context 
for the bearer termination. 



O 



This information element identifies the call 
as emergency call that requires a 
preferential handling. 



IVI 



This information element indicates the 
existing bearer termination or requests a 
new termination for the bearer to be 
established. 



O 



This information element specifies the used 
interface type for the IP termination (e.g. 
IVIbolP). 



This information element indicates the 
resource{s) (e.g. codec, auxiliary payload 
types) for which the TrGW shall be prepared 
to receive user data May be excluded (i.e. "- 
" is used in SDP m-line) if no transcoding or 
other media related functions are required. 



This information element indicates the 
resources (e.g. codec, auxiliary payload 
types) that the TrGW shall use to send user 
data. May be excluded (i.e. "-" is used in 
SDP m-line) if no transcoding or other media 
related functions are required. 



This information element indicates if multiple 
IP resources are to be reserved. This 
information element shall be included if a 
speech codec and auxiliary payload types 
are configured. 



M 



This information element requests an IP 
address and a port number on the TrGW 
that the remote end can send user plane 
data to. 



M 



This information element indicates the IP 
address and ports of the remote party that 
the TrGW can send user plane data to. 



O 



This information element indicates that 
remote source address filtering is required. 



This information element provides 
information on the valid remote source 
addresses. This may be included if remote 
source address filtering is included. It shall 
not be included if remote source address 
filtering is not included. 



O 



This information element indicates that 
remote source port filtering is required. 



This information element identifies the valid 
remote source port. This may be included if 
remote source port filtering is included. It 
shall not be included if remote source port 
filtering is not included. (NOTE 1) 



This information element identifies a range 
of valid remote source ports. This may be 
included if remote source port filtering is 
included. It shall not be included if remote 
source port filtering is not included. (NOTE 
ii 



O 



Indicates whether or not the TrGW shall 
reserve a port for an RTCP flow. 



M 



This information element requests 
termination heartbeat indications. 
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Notify Released 
Bearer 



IP Realm Identifier 



Traffic Policing 
Required 



Peak Data Rate 



Sustainable Data 
Rate 



Delay Variation 
Tolerance 



IVIaximum Burst Size 



DiffServ Code Point 



DiffServ Tagging 
Behaviour 



IVIedia Inactivity 
Detection Required 



Inactivity Detection 
Time 



Inactivity Detection 
Direction 



ECN Control 



Notify ECN Error 
Event 



O 



O 



O 



O 



O 



O 



O 



O 



O 



O 



O 



This information element requests a 
notification of a released bearer. 



This information element indicates the IP 
realm of the IP termination. 



This information element indicates that 
policing of the media flow is required. 



This information element may be present if 
Policing is required and specifies the 
permissible peak data rate for a media 
stream. (NOTE 2) 



This information element may be present if 
Policing is required and specifies the 
permissible sustainable data rate for a 
media stream. (NOTE 2) 



This information element may be present if 
Policing on Peak Data Rate is required and 
specifies the maximum expected delay 
variation tolerance for the corresponding 
media stream. 



This information element shall be present if 
Policing on Sustainable Data Rate is 
required and specifies the maximum 
expected burst size for the corresponding 
media stream. 



This information element indicates a specific 
DiffServ code point to be used in the IP 
header in packets sent on the IP 
termination. 



This information element indicates whether 
the Diffserv code point in thelP header in 
packets sent on the IP termination should be 
copied from the received value or set to a 
specific value. 



This information element indicates that 
detection of inactive media flows is required. 



This information element may be present if 
Inactive Media Detection is required and 
specifies the Inactivity Detection time. 



This information element may be present if 
Inactive Media Detection is required and 
specifies the Inactivity Detection direction. 



This information element either requests the 
TrGW to apply ECN procedures and IP 
header settings, and thus to act as an ECN 
endpoint, or indicates that ECN is active 
and ECN bits shall be passed transparently. 



This requests a notification if an error occurs 
due to ECN. It shall only be supplied if ECN 
Control is supplied with ECN endpoint value. 



Reserve and 

Configure TrGW 

Connection Point 

Ack 



TrGW 



Context 



M 



This information element indicates the 
context where the command was executed. 



Termination 



M 



This information element indicates the 
termination where the command was 
executed. 



Local IP Resources 



This information element indicates the 
resources that the TrGW has reserved to 
receive the user plane data from the remote 
side. This IE shall be present if it was 
contained in the request. 
If the IE was not contained in the request, it 
may be present in the reply. 



Remote IP Resources 



O 



This information element indicates the 
resource (i.e. codec) that the TrGW shall 
use to send user data. 



Local Connection 
Addresses 



M 



This information element indicates the IP 
address and port on the TrGW that shall 
receive user plane data. 
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Remote Connection 
Address 



O 



This information element indicates the IP 
address and port that the TrGW can send 
user plane data to. 



NOTE 1 : Remote Source Port and Remote Source Port Range are mutually exclusive. 
NOTE 2: At least one of these IBs shall be present when policing is required. 



Editor's Note: Details of ECN control IE are ffs, e.g. if this IE will be spilt in several information elements. 

1 0.4.1 .4 Release TrGW Termination 

This procedure is used to release multimedia-processing resources for a termination at the TrGW. 

Table 10.4.1.4.1: Release TrGW Termination 



Procedure 


Initiated 


Information 
element name 


Information 
element 
required 


Information element description 


Release TrGW 
Termination 


IBCF 


Context 


M 


This information element indicates the 
existing context. 


Termination 


M 


This information element indicates the 
existing bearer termination to be 
released. 


Release TrGW 

Termination 

Ack 


TrGW 


Context 


M 


This information element indicates the 
context where the command was 
executed. 


Termination 


M 


This information element indicates the 
termination where the command was 
executed. 



Note: No requirement for statistics in the Release TrGW Termination Ack has been justified by a use case. 



10.4.1.5 



IP Bearer Released 



Table 10.4.1.5.1: IP Bearer Released 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


IP Bearer 
Released 


TrGW 


Context 


M 


This information element indicates the 
context for the bearer termination. 


Termination 


M 


This information element indicates the bearer 
termination where the bearer was released. 


Bearer Released 


M 


This information element notifies a bearer 
release. 


Release Cause 


M 


This information element indicates the cause 
of a bearer release. 


IP Bearer 
Released Ack 


IBCF 


Context 


M 


This information element indicates all context 
are where the command was executed. 


Termination 


M 


This information element indicates that 

Bearer termination is where the command 

was executed. 
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10.4.1.6 Media Inactivity Detection 

This command is used to notify the IBCF of media inactivity on the TrGW. 

Table 10.4.1.6.1: Media Inactivity Notification 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Media Inactivity 
Notification 


TrGW 


Context 


M 


This information element indicates the 
existing context for the bearer termination. 


Termination 


M 


This information element indicates that 

bearer termination is where the media 

inactivity detection was activated. 


IVIedia Inactivity 


M 


This information element notifies the IBCF of 

Media inactivity detection on the bearer 

termination. 


IVIedia Inactivity 
Notification Acl< 


IBCF 


Context 


M 


This information element indicates the 
context where the command was executed. 


Termination 


M 


This information element indicates the bearer 

termination where the command was 

executed. 



10.4.1 .7 Termination heartbeat indication 

This command is used by the TrGW to periodically notify the IBCF of a termination heartbeat. 

Table 10.4.1.7.1: Termination heartbeat indication 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Termination 
heartbeat 
indication 


TrGW 


Context 


M 


This information element indicates the 
context for the bearer termination. 


Bearer Termination 


M 


This information element indicates the bearer 
termination for which the termination 
heartbeat is reported. 


Termination heartbeat 


M 


Hanging Termination event 


Termination 

heartbeat 

indication Ack 


IBCF 


Context 


M 


This information element indicates the 
context where the command was executed. 


Bearer Termination 


M 


This information element indicates the bearer 
termination where the command was 
executed. 
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1 0.4.1 .8 Change Through-Connection 

This procedure is used to change the Through-connection in the bearer termination. 

Table 10.4.1.8.1: Change Through-Connection 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


Change Through- 
Connection 


IBCF 


Context/Context 
Request 


M 


This information element indicates the 
existing context or requests a new context for 
the bearer termination. 


Bearer 

Termination/Bearer 

Termination Request 


M 


This information element indicates the 
existing bearer termination or requests a new 
Bearer termination where the through 
connection is changed. 


Through-Connection 


M 


This information element indicates the 
through-connection of the bearer termination 


Change Through- 
Connection Acl< 


TrGW 


Context 


M 


This information element indicates the 
context where the command was executed. 


Bearer Termination 


M 


This information element indicates the bearer 
termination where the command was 
executed. 



NOTE: This procedure may be combined with Reserve and Configure TrGW Connection Point, Reserve TrGW 
Connection Point or Configure TrGW Connection Point procedure. This Hst of procedures is not 
exhaustive. 

1 0.4.1 .9 ECN error Indication 

This procedure is used to report ECN related errors (see clause 10.2.13.3a). 

Table 10.4.1.9.1: Procedures toward the IM Subsystem: ECN Error Indication 



Procedure 


Initiated 


Information element 
name 


Information 
element 
required 


Information element description 


ECN Error 
Indication 


TrGW 


Context 


M 


This information element indicates the 
context for the bearer termination. 


Bearer Termination 


M 


This information element indicates the 
bearer termination for which the termination 
heartbeat is reported. 


ECN Error Indication 


M 


This IE indicates an ECN error event. 


ECN Error 
Indication Ack 


IBCF 


Context 


M 


This information element indicates the 
context where the command was executed. 



10.4.2 Non Call related Procedures 

The procedures in Table 10.4.2.1 shall be applied between the IBCF and TrGW. 
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Table 10.4.2.1: Non-call related procedures 



Stage 3 Procedure (for information) 

defined in 

3GPP TS 29.238 [25] 


Corresponding Stage 2 Procedure 

defined in 

3GPP TS 23.205 [28] 


Remarks 


TrGW Out of service 


IVIGW Out of Service 




TrGW Communication Up 


IVIGW Communication Up 




TrGW Restoration 


IVIGW Restoration 




TrGW Register 


IVIGW Register 




TrGW Re-register 


IVIGW Re-register 




CS-IBCF Ordered Re-register 


(G)IVISC Server Ordered Re-register 




CS-IBCF Restoration 


(G)IVISC Server Restoration 




CS-IBCF Out of Service 


(G)MSC Server Out of Service 




Termination Out-of-Service 


Termination Out-of-Service 


The 'Termination Out-of-Service 
procedure' is also used as a call- 
related H.248 command 


Audit Value 


Audit Value 




Command Rejected 


Command Rejected 


The 'Command Rejected' procedure 
may be used in response both to 
call-related and non-call-related 
H.248 Commands. 


TrGW Capability Change 


Capability Update 




TrGW Resource Congestion Handling 
- Activate 


IVIGW Resource Congestion 
Handling -Activate 




TrGW Resource Congestion Handling 
- Indication 


IVIGW Resource Congestion 
Handling - Indication 




Inactivity timeout activation 


Inactivity timeout activation 




Inactivity timeout indication 


Inactivity timeout indication 




Realm Availability Change Activation 




See 3GPP TS 29.235 [29] subclause 
A.7.2 


Realm Availability Change Indication 




See 3GPP TS 29.235 [29] subclause 
A.7.2 
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Annex A (informative): 

Codecs used for conversational services 

Codecs used for Conversational Services For codecs for conversational services in the PS domain are defined according 
to 3GPP TS 26.235 [6]. These include: 

Narrowband speech: The support of the AMR codec is mandated. 

For wideband speech: The support of the AMR-WB codec is mandated 

For video: The support of the H.263 profile level 10 vl is mandated, and the support of MPEG4 visual sp @ 
level and ITU-T Recommendation H.263 [14] profile 3 level 10 are optional. 

In non-3GPP SIP networks there are no mandatory codecs. However, the following codecs are of interest: 

Narrowband speech: ITU-T Recommendations G. 723.1 [15], G.729 [16] and G.711 [17] are known to be 
commonly deployed. 

Video codecs: ITU-T Recommendation H.263 [14] and MPEG4 are expected to be used. 
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Annex B (informative): 
Change history 
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TSG Doc. 
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Rev 


Subject/Comment 
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2001-11 
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0.6.0 
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